A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the United States Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
1. Field of the Invention
The present invention is directed to systems, such as voice messaging systems, in which call flows of a network application are executed to provide telephony-related services, such as Call Answer, Call Forward, Voice Store and Forward, Voice Mail, Bank By Phone, Emergency Number Facilities, Directory Assistance, Operator Assistance, Call Screening, Automatic Wake-up Services, and the like. More particularly, the present invention is directed to methods and apparatus for providing external program access to the executable call flows of a network application.
2. Description of the Prior Art
U.S. Pat. No. 5,133,004, issued Jul. 21, 1992 and assigned to the assignee of the present invention, describes a Network Applications Platform commercially available from UNISYS Corporation (xe2x80x9cthe NAP systemxe2x80x9d). The NAP system is a configuration of hardware and software that provides data and voice processing capabilities through applications running on an enterprise server. The NAP system provides the interface between these applications, called network applications, and a telephone network. Network applications running on the NAP system can provide enhanced services for telephone networks, such as Call Answer, Call Forward, Voice Store and Forward, Voice Mail, Bank By Phone, Emergency Number Facilities, Directory Assistance, Operator Assistance, Call Screening, Automatic Wake-up Services, and the like. The NAP can be implemented on UNISYS A Series and ClearPath HMP computer systems running the MCP operating system. Further details of the structure and function of the NAP are provided in U.S. Pat. No. 5,133,004, which is hereby incorporated by reference in its entirety.
A network application is an application program that executes on a telephony-based system, such as the NAP system, to provide telephony-related services, such as Call Answer, Call Forward, Voice Store and Forward, Voice Mail, Bank By Phone, Emergency Number Facilities, Directory Assistance, Operator Assistance, Call Screening, Automatic Wake-up Services, and the like. A network application comprises one or more call flows which determine the functionality of the application. A call flow defines how a call is processed from the time it is connected until it is disconnected. It determines how a network application will react to various telephony-related events. In particular, a call flow specifies each function or processing step to be executed during a telephone call, the possible results for each function, the decision path to be followed based on the result, and each prompt or voice message to be played during the course of the telephone call. A call flow is comprised of a sequence of call states. As used herein, the phrase xe2x80x9cto play a promptxe2x80x9d and variations thereof means to output the digitized voice of a prompt over a telephone connection or the like so that it can be heard by a caller. A call state is one state, or point, in a call flow. At any given time, each call coming into a network application has a finite call state. At a given call state, a given function is performed and the results of the function point either to a next state, or to an exit state. The function can lead to one or many results.
FIG. 1 illustrates the call flows of an exemplary network application that can be executed on the UNISYS NAP system. In the example shown, the network application comprises two call flowsxe2x80x94CALLFLOW1 and CALLFLOW2. CALLFLOW1 might, for example, provide voice mail services, while CALLFLOW2 might provide automated call answering services. Each box 10-26 in FIG. 1 represents one call state.
On the NAP system, a network application developer can specify different call types to be handled by a network application. Each call type can be serviced by a different call flow and has a unique identifier associated with it. An Incoming Call (INCMG) state 12 is the first call state in every network application. The INCMG call state 12 identifies the type of call received by the NAP system and routes that call to the appropriate call flow of the application. In the example of FIG. 1, a first call type is routed to the voice mail call flow which has a call flow identifier of xe2x80x9c001,xe2x80x9d whereas a second call type is routed to the call answering call flow which has a call flow identifier of xe2x80x9c002.xe2x80x9d The different call types must be specified in the network application, and they must also be defined to the NAP system when the network application is installed and initialized on the system. Once the different call types have been defined, the NAP system is able to identify the different call types and to return the appropriate call flow identifier in the INCMG call state 12 when a call is received, so that the call can be processed by the appropriate call flow. Each call processed by the NAP system is referred to as a dialog.
At each subsequent call state in a call flow, some function is performed. On the NAP system, a call flow can execute two kinds of functionxe2x80x94core functions and custom functions. Core functions are pre-coded functions provided with the NAP system. These functions provide basic telephony services such as initiating a call, playing a voice prompt, collecting digits, and the like. Custom functions are application-specific functions that the application developer creates to perform functions not available using the core functions. For example, the application may require the retrieval of information from an application-specific database. Custom functions can be written in any programming language that the underlying computer system (e.g. UNISYS A Series or ClearPath HMP) on which the NAP system is implemented can execute, such as, for example, LINC, ALGOL, COBOL, C or the like.
Referring to the example of FIG. 1, the voice mail call flow (CALLFLOW1) proceeds to call state 14, at which the Play Prompt (PROMPT) core function is executed to play prompt number xe2x80x9cP1000xe2x80x9d to the caller. This prompt might, for example, play the following voice: xe2x80x9cYou have  less than number greater than  new messagesxe2x80x94Press 1 to review, Press 2 for other options.xe2x80x9d Based on the user""s selection, the call flow will then pass to a next state at which another function will be performed. Ultimately, the dialog established for this call will end at call state 16 which performs the Terminate Dialog core function.
When a call of type xe2x80x9c002xe2x80x9d is received, the call will be routed to CALLFLOW2. At call state 18, this call flow might prompt the caller to xe2x80x9cPress 1 to hear prompts in English, Press 2 to hear prompts in Spanish, or Press 3 to hear prompts in French.xe2x80x9d This time the Play Prompt core function (PROMPT) is combined with a Collect Digits function so that the NAP system will accept a caller""s response. If the caller presses xe2x80x9c1xe2x80x9d, the call flow will move to call state 20 where a Set Language core function is performed to set the active language to American English. If the caller presses xe2x80x9c2,xe2x80x9d the call flow moves to call state 22 where the Set Language core function is performed to set the active language to American English. If no key is pressed, or an invalid key is pressed, the call flow defaults to step 24 which establishes the American English language as the default. The remainder of the call flow then proceeds until the dialog established for the call terminates at call state 26. As the foregoing illustrates, the INCMG call state, in combination with defined call types, can be used to handle different types of calls within a single network application.
On the NAP system, network applications are created using two personal computer (PC) based applicationsxe2x80x94PC SPIN and PC NAPTool. PC SPIN is a modified form of the SPIN program described in commonly assigned U.S. Pat. No. 5,493,606, and is used by an application developer to create and modify sets of prompt definitions and related information required to expand and play prompts on the system. PC NAPTool is used by a network application developer to create and edit the call flows of a network application. The PC SPIN and PC NAPTool programs run in the Microsoft Windows environment. Further details concerning the use of the PC SPIN and PC NAPTool programs to create a network application are provided in U.S. Pat. No. 5,493,606 and in co-pending application Ser. No. 08/944,924, filed Oct. 6, 1997, entitled xe2x80x9cEnhanced Multi-Lingual Prompt Management In A Voice Messaging System With Support For Speech Recognition,xe2x80x9d both of which are hereby incorporated by reference in their entireties.
Once created, the files and information comprising a network application are transferred from the PC environment to the NAP system. An Installation Manager program takes the transferred information and installs it in appropriate files on the host computer of the NAP system (e.g., UNISYS A Series or ClearPath HMP computer) for use during execution of the network application. In particular, a representation of each call flow of the network application is stored in a CALLFLOWS file. This file specifies the functions to be performed at each call state and the logic that controls the flow of execution from state-to-state. An INSPARAM file contains certain installation parameters associated with the network application. A COREDEF file provides certain default input parameters for certain core functions, particularly those that may require site-specific changes, and a CUSTATTR file contains attributes of all custom functions written for the network application.
A network application executes in a runtime environment on the NAP system. Multiple network applications can be installed and run on a single NAP platform, with each network application running in its own runtime environment. The runtime environment for a given network application includes a core function library (part of the agent) that contains the executable code for each core function, and a custom function library that contains the executable code for each custom function written for the network application. Another interface (not shown) exists to provide access to custom functions written in the LINC programming language.
A primary component of the runtime environment is called the agent. The agent is a software component that (i) performs and controls call flow execution (the next function to be executed is based on the result of the previous function), (ii) passes parameters to various functions, (iii) translates new dialog activity into call states, (iv) saves information from NAP responses for use during call flow execution, and (v) enters call flow information into memory-based state tables. Execution of a call flow by the agent is interpretive; the agent interprets the representation of the call flow contained in the CALLFLOWS file. At each call state, the agent invokes the specified core function or custom function from the appropriate library.
It would be desirable if the call flows of a network application could be called externally from another application program. That other application program could be another network application running in its own environment on the host system or some other non-telephony based application running on the host computer (outside of the NAP environment) or on another computer. For example, the developer of a database application for use by mortgage lenders that identifies delinquent mortgage payments might want to provide the ability to automatically call the delinquent borrower and play a voice prompt reminding the borrower of the delinquent payment. An installed network application may already have a call flow that provides this functionality, and therefore, it would be desirable for the database application developer to be able to make an external call to that call flow, rather than developing new code to perform the same function. Accordingly, there is a need for methods and apparatus for providing external program access to the executable call flows of a network application. The present invention satisfies this need.
The present invention is directed to methods and apparatus for providing external program access to the executable call flows of a network application. More specifically, in a computer system that has an interface to a telephone network and that executes network applications that provide telephony services to callers over the network, the present invention provides an interface between one or more network applications and a client application to enable the client application to externally call and initiate execution of a selected call flow of one of the network applications. This is a powerful tool that enables developer""s of client applications to take advantage of existing telephony-related functionality provided by one or more network applications, avoiding the need to reinvent or reproduce complicated telephony code in the client application. Additionally, the present invention allows new network applications to take advantage of the call flows of other, existing network applications. The present invention thus provides a unique form of code reuse that results in a tremendous savings of time and effort during application development.
According to a preferred embodiment, the methods and apparatus of the present invention are embodied in a call flow library that comprises a set of procedures that enable a client application to call and initiate execution of a selected call flow of a selected network application. Each network application establishes a link to the call flow library, and each linkage has a unique connection index associated therewith. A routing table, which is part of the call flow library, contains an entry for each network application that specifies a name associated with the network application and the connection index associated with its linkage to the call flow library. Each entry in the routing table is identified by a slot number (SLOT #). A client application that wants to execute a particular call flow of a selected network application calls a first procedure (GETLIBINX) of the call flow library that contains programmed instructions that cause the computer system to access the routing table and to return to the client application an indication of the connection index associated with the link between the call flow library and the selected network application. Specifically, in the preferred embodiment, the first procedure uses the name associated with the selected network application to access the routing table and to return the SLOT # of the entry in the routing table for that network application. The SLOT # serves as an indication of the connection index for the selected network application, since it can then be used to retrieve the connection index from the routing table entry that it identifies. Alternatively, the first procedure could return the connection index directly.
The client application then calls a second procedure (CALLFLOW_INTERFACE) that contains programmed instructions for causing the computer system to initiate, via the linkage identified by the connection index indicated by the first procedure, execution of a selected call flow of the selected network application. An identifier of the selected call flow and information needed to initialize the selected call flow for proper execution are passed to the selected network application as input parameters of the second procedure. The call flow library may further comprise a third procedure (REGISTER_APP) that is called by a network application upon initialization of that network application on the computer system. This third procedure contains programmed instructions that cause the computer system to establish a link between the network application and the call flow library and to store, in an entry (identified by a particular SLOT #) in the routing table, a connection index associated with that link. The third procedure also stores in that entry a name(s) associated with the network application.
Additional features and advantages of the present invention will become evident hereinafter.